IP multicasting provides an efficient way for a source to send a stream of User Datagram Protocol (UDP) packets to a set of recipients. The source sends only one copy of each packet to an IP network, such as the Internet, for example. The routers in the IP network do the work required to deliver that packet to each recipient. Various IP multicast routing protocols can be used in an IP network. These allow the routers to communicate with each other so that the multicast datagrams are sent only to those subnetworks with receivers that have joined a multicast session.
A multicast session is identified by an IP address and port number. The IP address is a Class D address in the range from 224.0.0.1 to 239.255.255.255. IP multicasting is more efficient than unicasting for group communication. Unicasting requires that the source send a separate copy of each datagram to each recipient. This requires extra resources at the source and in the IP network and is wasteful of network bandwidth.
Some useful background references describing IP multicasting in greater detail include: (1) Kosiur, D., IP Multicasting: The Complete Guide to Corporate Networks, Wiley, 1998; (2) Maufer, T., Deploying IP Multicast in the Enterprise, Prentice-Hall, 1997; (3) Deering, S., xe2x80x9cHost Extensions for IP Multicasting,xe2x80x9d Network Working Group Request for Comments Internet RFC-1112, August 1989; (4) Waitzman, D., Partridge, C., Deering, S., xe2x80x9cDistance Vector Multicasting Routing Protocol,xe2x80x9d Network Working Group Request for Comments Internet RFC-1075, November 1988; (5) Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., xe2x80x9cRTP: A Transport Protocol for Real-Time Applications,xe2x80x9d Network Working Group Request for Comments Internet RFC 1889, Jul. 18, 1994. The IP multicast protocol set forth in the IETF RFC 1112 xe2x80x9cHost Extensions for IP Multicastingxe2x80x9d is the standard protocol for enabling hosts to establish and conduct IP multicast sessions on the Internet. The IETF RFC 1075, xe2x80x9cDistance Vector Multicast Routing Protocol (DVMRP),xe2x80x9d describes a protocol for propagating routing information among multicast-enabled routers.
The multicast backbone on the Internet (Mbone) is an extension of the Internet backbone to support IP multicasting. The Mbone is formed collectively by the portion of the network routers in the Internet backbone that are programmed to perform the IP multicast routing protocol. Those routers in the Internet backbone that are programmed to handle IP multicast sessions, as well as unicast sessions, are referred to herein as multicast-enabled routers. The Mbone is a virtual network that is layered on top of sections of the physical Internet. It is composed of islands of multicast-enabled routers connected to each other by virtual point-to-point links called xe2x80x9ctunnels.xe2x80x9d The tunnels allow multicast traffic to pass through the non-multicast-enabled routers of the Internet. IP multicast packets are encapsulated as IP-over-IP, so that they look like normal unicast packets to the intervening routers. The encapsulation is added upon entry to a tunnel and removed upon exit from a tunnel. This set of multicast-enabled routers, their directly connected subnetworks, and the interconnecting tunnels define the Mbone. For additional details, see (1) Comer, Douglas E. Internetworking with TCP/IP: Volume 1-Principles, Protocols, and Architecture, Third Edition. Englewood Cliffs, N.J.: Prentice Hall, 1995; (2) Finlayson, Ross, xe2x80x9cThe UDP Multicast Tunneling Protocolxe2x80x9d, IETF Network Working Group Internet-Draft, published Sep. 9, 1998, http://search.ietf.org/internet-drafts/draft-finlayson-umtp-03.txt; and (3) Eriksson, Hans, xe2x80x9cMBone: The Multicast Backbone,xe2x80x9d Communications of the ACM, August 1994, Vol.37, pp.54-60.
Since the multicast-enabled routers of the Mbone and the non-multicast-enabled routers of the Internet backbone have different topologies, multicast-enabled routers execute a separate routing protocol to decide how to forward multicast packets. The majority of the Mbone routers use the Distance Vector Multicast Routing Protocol (DVMRP), although some portions of the Mbone execute either Multicast OSPF (MOSPF) or the Protocol-Independent Multicast (PIM) routing protocols. For more details about PIM, see: Deering, S., Estrin, D., Farrinaci, D., Jacobson, V., Liu, C., Wei, L., xe2x80x9cProtocol Independent Multicasting (PIM): Protocol Specificationxe2x80x9d, IETF Network Working Group Internet Draft, January, 1995.
Multicasting on the Internet has a unique loss environment. On a particular path the losses occur in bursts, as multicast-enabled routers become congested, rather than the losses having the characteristics associated with white noise. When packets are lost on a particular link in the multicast tree, any downstream receivers lose the same packet. Therefore, a large number of retransmissions may occur at the same time in response to negative acknowledgments from receivers. One problem is that such retransmissions are typically in multicast sessions which will tend to encounter the same congested nodes as did the original multicast sessions.
However, congestion in different parts of network is not correlated since traffic to receivers in other parts of the multicast tree does not necessarily pass through the same congested nodes and therefore does not lose the same bursts of packets. Therefore, path diversity would be a good means for recovering at least some of the missing packets, if there were a way to coordinate such a recovery.
Another problem in IP multicasting is that some Internet Service Providers (ISPs) discriminate against multicast packets and discard them before discarding the packets for other services. Therefore, it would be worthwhile balancing the efficiency of multicast transmissions with the quality of point-to-point transmissions.
These problems have been solved by the Network-Based Service for the Repair of IP Multicast Sessions described in the above referenced, copending U.S. patent application by Maxemchuk, et al. In the Maxemchuk, et al. system, a repair server polls multiple transmit servers to accumulate as many of the packets missing from the multicast session as possible. This improves the quality of audio and video multicasts of live conferences, news broadcasts and similar material from one source to many receivers over the Internet.
The invention disclosed herein is an improvement to the Maxemchuk, et al. system, to provide authentic, paying subscribers an automatic repair service for the multicast sessions they receive. The invention disclosed herein also provides for the receiving subscriber to be authorized by a subscription server that causes the subscriber to be billed for the repair service.
The invention is a system and method for recipient-initiated automatic repair of IP multicast sessions. In one aspect of the invention, a multicast application on a receiver issues a request to join an IP multicast session xe2x80x9cXxe2x80x9d. A translator/decryption module (TDM) on the receiver intercepts this request and sends it to a controller on a repair server. The controller sends a request to a subscription server to determine if this user has subscribed to the repair service. The controller upon receipt of a positive response from the subscription server, then determines whether a repair/encryption module (REM) exists for this multicast session. If it does not receive such a response, then the controller selects an IP multicast address, port number and decryption key for a new IP multicast session xe2x80x9cYxe2x80x9d. This information is returned to the TDM. The controller creates a repair/encryption module (REM) and provides the IP multicast address and port number for the new IP multicast session xe2x80x9cYxe2x80x9d and an encryption key to the REM. Then, the TDM stores the session xe2x80x9cYxe2x80x9d IP multicast address, port number and decryption key.
The REM reads packets from IP multicast session xe2x80x9cXxe2x80x9d and checks if there are any missing packets. If there are missing packets, it requests one or more retransmit servers for session xe2x80x9cXxe2x80x9d to obtain the missing packets. The repair/encryption module encrypts the packets and writes them to IP multicast session xe2x80x9cYxe2x80x9d. The packets for IP multicast session xe2x80x9cYxe2x80x9d are processed by the IP stack on the receiver, and are then sent to the translator/decryption module (TDM). The TDM decrypts these packets, modifies the destination IP address and port number from the values for session xe2x80x9cYxe2x80x9d to those for session xe2x80x9cXxe2x80x9d. The packets are then sent to the application. The application then presents the message contained in the packets to the subscriber of the IP multicast xe2x80x9cXxe2x80x9d.